Реляционные базы данных
Реляционная модель данных (РМД) некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними. Термины РМД представлены в табл. 5.1 [17|.
Таблица 5.1 Термины реляционной модели
Термин
реляционной
модели Эквивалентный термин
Отношение Таблица
Схема отношения Строка заголовков столбцов таблицы (заголовок таблицы)
Кортеж Строка таблицы, запись
Сущность Описание свойств объекта
Атрибут
Домен Множество допустимых значений атрибута
Первичный ключ Уникальный идентификатор
Кардинальное и, Количество строк
Степень Количество столбцов
Реляционная база данных представляет собой хранилище данных,
содержащее набор двухмерных таблиц. Данные в таблицах должны удовлетворять следующим принципам.
1. Значения атрибутов должны быть атомарными (иными слонами, каждое значение, содержащееся па пересечении строки и колонки, должно быть не расчленяемым на несколько значений).
2. Значения каждого атрибута должны принадлежать к одному и тому же типу.
3. Каждая запись в таблице уникальна.
1. Каждое поле имеет уникальное имя.
5. Последовательность полей и записей в таблице несущественна
Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.
Сущность есть объект любой природы, данные о котором хранятся в базе данных. Данные о СУЩНОСТИ хранятся в отношении.
Атрибуты представляют собой свойства, характеризующие сущность. В структуре таблицы каждый атрибут именуется и ему соответствует заголовок некоторого столбца таблицы.
Математически отношение можно описать следующим образом.
Пусть даны n множеств D1 ,D2, D3, Dn , тогда отношение R есть множе-
ство упорядоченных кортежей
, где dk e Dk, dk - атри
бут, a Dk, - домен отношения R.
На рис. 5.3 приведен пример отношения «СОТРУДНИК» [49|.
Домен представляет собой множество всех возможных значений определенного атрибута отношения. Отношение «СОТРУДНИК» включает 4 домена: 1) множество всех возможных фамилий сотрудников;
2) множество всех возможных номеров отделов;
3) множество всех возможных названий должностей;
4) множество возможных дат рождения сотрудников.
Значения домена принадлежат к одному типу (числовому, символьному и т. д.).
Отношение «СОТРУДНИК» содержит 3 кортежа (кортежу соответствует строка таблицы). Информация о предметной области ВНОСИТСЯ ПО 4-м атрибутам.
Схема отношения — перечень имен атрибутов. Например: СОТРУДНИК (ФИО, Отдел, ДОЛЖНОСТЬ, Дата рождения). Множество кортежей отношения называют телом отношения.
Ключом отношения называется совокупность его атрибутов, однозначно идентифицирующих каждый из кортежей отношения. Иными словами, множество атрибутов К, являющееся ключом отношения, обладает СВОЙСТВОМ уникальности. Следующее свойство ключа — неизбыточность. То есть никакое из собственных подмножеств множества K не обладает свойством уникальности [18].
Каждое отношение всегда имеет комбинацию атрибутов, которая может служить ключом. Ее существование гарантируется принципом №3 РМД. По крайней мере, вся совокупность атрибутов обладает свойством уникальности.
ВОЗМОЖНЫ случаи, когда отношение имеет несколько комбинаций атрибутов, каждая ИЗ которых однозначно определяет все кортежи отношения. Все эти комбинации атрибутов являются возможными ключами отношения. Любой из возможных ключей может быть выбран
как первичный.
Ключи обычно ИСПОЛЬЗУЮТ ДЛЯ достижения следующих целей [18]:
¦ исключения дублирования значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются);
¦ упорядочения кортежей. Возможно упорядочение по возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (по одним возрастание, а по другим — убывание);
¦ организации связывания таблиц.
Важным является понятие внешнего ключа. Внешний ключ можно определить как множество атрибутов одного отношения R2, значения которых должны совпадать со значениями возможного ключа другого отношения R [18].
Атрибуты отношения R2, составляющие внешний ключ, не являются ключевыми для данного отношения.
С помощью внешних ключей устанавливаются связи между отношениями.
Например, имеются два отношения: отделы (код отдела, название, число сотрудников) и сотрудники (код сотрудника, ФИО, код отдела, зарплата). Атрибуты, выделенные жирным шрифтом, являются первичными ключами. Атрибут, выделенный курсивом, является внешним ключом (см. рис. 5.4). Внешний ключ отношения СОТРУДНИКИ Код отдела" является первичным ключом отношения ОТДЕЛЫ.
Ограничения целостности реляционной модели МОЖНО разделить на две группы — ограничения целостности сущностей и ограничения целостности ссылок.
Ограничения целостности сущностей заключаются в требовании уникальности кортежей отношения (записей таблицы). Отсюда вытекают следующие ограничения [18]:
¦ отсутствие кортежей-дубликатов (данное требование предъявляется лишь к атрибутам первичных ключей);
¦ отсутствие атрибутов с множественным характером значений.
Ограничения целостности ссылок заключаются в том, что для любой записи с конкретным значением внешнего ключа должна обязательно существовать запись связанной таблицы-отношения с соответствующим значением первичного ключа. Примером этого требования
является отношение «СОТРУДНИКИ» С внешним ключом «Код отдела" и связанная с ней таблица ОТДЕЛЫ с первичным ключом «Код отдела» (см. рис. 5.4). Если существует сотрудник Волков II. П., работающий В отделе O1, то соответствующий отдел должен существовать и данные о нем должны храниться в таблице ОТДЕЛЫ [49].
К отношениям можно применять систему операций, позволяющую получать одни отношения из других. Например, результатом запроса к реляционной БД может быть новое отношение, вычисленное па основе имеющихся отношений. Поэтому можно разделить обрабатываемые данные па хранимую и вычисляемую части.
Основной единицей обработки данных в реляционных БД является отношение, а не отдельные его кортежи (записи).
Отсутствие упорядоченности записей в таблицах усложняет поиск.
На практике с целью быстрого нахождения нужной записи вводят индексирование полей (обычно ключевых). Создание индексных массивов заключается в построении дополнительной упорядоченной информационной структуры ДЛЯ быстрого доступа к закисям.
Как ДЛЯ самих таблиц, так и для индексных массивов применяются линейные и нелинейные структуры. В качестве линейных структур
индексных массивов в большинстве случаев выступают инвертированные СПИСКИ. Инвертированный СПИСОК строится ПО схеме таблицы с двумя колонками «Значение индексируемого поля» и «Номера
строк» (рис. 5.5) | 14].
Значение индексируемого поля («Год рождения») Номера строк
1970 3
1971 5,17, 123,256
1972 31,32,77
1973 11,45,58,167,231
1974 7,8,9, 10,234,235,236
Рис. 5.5. Пример инвертированного списка
Инвертированные списки чаще всего применяются для индексации полей, значения которых в разных записях могут повторяться. В этом
130
случае количество ситуаций, при которых требуется добавление или удаление строк индекса, невелико и затраты на переупорядочение индекса при изменениях данных в базовой таблице незначительны.
Строки инвертированного списка упорядочиваются по значению индексируемого ноля. Для доступа к нужной записи исходной таблицы сначала в упорядоченном инвертированном списке отыскивается строка с требуемым значением ноля, затем с считываются номера соответствующих записей основной таблицы, к которым осуществляется доступ по этим номерам.
Нелинейные структуры индексов применяются для создания индексных массивов ключевых полей или тех полей, значения по которым не повторяются. При организации индексов в таких случаях чаще всего используются древовидные иерархические структуры в виде В-деревьев [14].
5.4. Проектирование реляционных баз данных
Проектирование баз данных информационных систем является достаточно трудоемкой задачей. Оно осуществляется на основе формализации структуры и процессов предметной области, сведения о которой
предполагается хранить в БД. Различают концептуальное и схсмноструктурное проектирование.
Концептуальное проектирование БД ИС является в значительной степени эвристическим процессом. Адекватность построенной в его рамках инфологической модели предметной области проверяется опытным путем, в процессе функционирования ИС.
Перечислим этапы концептуального проектирования [14]:
¦ изучение предметной области для формирования общего представления о ней;
¦ выделение и анализ функций и задач разрабатываемой ИС;
¦ определение основных объектов-сущностей предметной области и отношений между ними;
¦ формализованное представление предметной области.
При проектировании схемы реляционной БД можно выделить следующие процедуры [14]:
¦ определение перечня таблиц и связей между ними;
¦ определение перечня полей, типов полей, ключевых полей каждой таблицы (схемы таблицы), установление связей между таблицами через внешние ключи;
¦ установление индексирования для полей в таблицах;
¦ разработка списков (словарей) Для полей с перечислительными данными;
¦ установление ограничений целостности для таблиц и связей;
¦ нормализация таблиц, корректировка перечня таблиц и связей.
Проектирование БД осуществляется на физическом и логическом уровнях. Проектирование на физическом уровне реализуется средствами СУБД и зачастую автоматизировано.
Логическое проектирование заключается в определении числа и структуры таблиц, разработке запросов к БД, отчетных документов, создании форм для ввода и редактирования данных в БД и т. д.
ОДНОЙ из важнейших задач логического проектирования БД является структуризация данных. Выделяют следующие подходы к проектированию структур данных [14]:
¦ объединение информации об объектах-сущностях в рамках одной таблицы (одною отношения) с последующей декомпозицией на несколько взаимосвязанных таблиц на основе процедуры нормализации отношений;
¦ формулирование знаний о системе (определение типов исходных данных и взаимосвязей) и требований к обработке данных, получение с помощью CASH системы ГОТОВОЙ схемы БД или даже ГОТОВОЙ прикладной информационной системы;
¦ осуществление системного анализа и разработка структурных моделей.
Рассмотрим первый из названных подходов, ЯВЛЯЮЩИЙСЯ классическим.
Процесс проектирования начинается с выделения обьектов-сущностей, информация о которых будет храниться в БД, и определения их атрибутов. Выделенные атрибуты объединяются в ОДНОЙ таблице (отношении).
Полученное отношение подвергается нормализации.
Процедура нормализации является итерационной и заключается в последовательном переводе отношений из первой нормальной формы в нормальные формы более ВЫСОКОГО порядка.
Выделяют следующую последовательность нормальных форм:
¦ первая нормальная форма (1НФ);
¦ вторая нормальная форма (2НФ);
¦ третья нормальная форма (ЗНФ);
132
¦ усиленная третья нормальная форма, или нормальная форма Бой
са-Кодда (БКНФ);
¦ четвертая нормальная форма (4НФ);
¦ пятая нормальная форма (5НФ).
Нормализация позволяет устранить информационную избыточность, которая приводит к аномалиям обработки данных.
Вместе с тем, следует различать неизбыточное и избыточное дублирование данных. Наличие первого из них в базах данных допускается. Приведем примеры обоих вариантов дублирования [49].
Пример неизбыточного дублирования данных представляет отношение «ТЕЛЕФОНЫ» (рис. 5.6) [49]. Предположим, что водной комнате установлен только один телефон, тогда номера телефонов сотрудников, находящихся в одном помещении, совпадают. Номер телефона 21212 встречается несколько раз. В этом состоит дублирование. Однако для каждого сотрудника номер уникален и при удалении одного из номеров будет утеряна информация о том, по какому номеру можно дозвониться до того или иного сотрудника в этом, состоит неизбыточность.
Рис. 5.6. Неизбыточное дублирование данных
Избыточное дублирование данных имеет место в отношении «КОМ-11ЛТЫ», в которое добавлен атрибут «Номер комнаты» (рис. 5.7) [49].
Сотрудники Белкин. Синицын и Медведев находятся в одной комнате и. следовательно, имеют одинаковые номера. То есть номер те-
лефона Синицина и Медведева можно узнать из кортежа со сведениями о Белкине. В этом и состоит избыточность дублирования данных.
Избыточное дублирование данных приводит к проблемам обработки кортежей отношения, названным Э. Коддом «аномалиями обновления отношения».
Аномалиями называются такие ситуации в таблицах БД, которые приводят к противоречиям в БД или существенно усложняют обработку данных [49].
Выделяют три основных вида аномалий:
¦ аномалии модификации (редактирования);
¦ аномалии удаления;
¦ аномалии добавления.
Аномалии модификации проявляются в том, что изменение значения атрибута может повлечь за собой пересмотр всей таблицы с соответствующим изменением значений этого атрибута в других записях таблицы.
Так, изменение номера телефона в комнате 325 (рис. 5.7) [49] потребует пересмотра всей таблицы «КОМНАТЫ" и изменения значений атрибута «Номер телефона» в записях, в которых встречается
ЭТОТ номер.
Аномалии удаления проявляются в том, что при удалении какого-либо значения атрибута исчезнет другая информация, которая не связана напрямую с удаляемым значением.
Так, удаление записи о сотруднике Волкове (например, по причине
увольнения) приводит к исчезновению информации о номере телефона, установленного в 320-й комнате (см. рис. 5.7).
Аномалии добавления проявляются в том, что невозможно добавить запись в таблицу, пока не будут известны значения всех ее атрибутов, а также в том, ЧТО вставка новой записи потребует пересмотра всей таблицы.
Например, в таблице <КОМНАТЫ» (см. рис. 5.7) невозможно отразить информацию о комнате с установленным в ней телефоном до тех пор, пока в нее не помешен ни один сотрудник (при условии, что поле «ФИО» является ключевым).
Кроме того, при добавлении в таблицу информации о новом сотруднике необходимо проверять таблицу на предмет противоречий, которые могут возникнуть при ошибочном вводе номера телефона или комнаты. Пример противоречия: сотрудники находятся в одной комнате, но имеют разные номера телефонов.
Способом устранения избыточного дублирования и нейтрализации аномалий является декомпозиция, то есть, разбиение исходного отношения (таблицы). Декомпозиция должна быть обратимой, то есть осуществляться без потери информации
На рис. 5.8 показан пример отношения «ГОРОДА» и приведены два варианта его декомпозиции [18].
Рис. 5.8. Отношение «ГОРОДА» и два варианта его декомпозиции
В варианте а) информация не утрачивается, ПОСКОЛЬКУ отношения все еще содержат данные о том, что город с кодом К1 имеет статус 30 и называется Париж, а городе номером К2 имеет статус 30 и называется Афины. Таким образом, первая декомпозиция является декомпозицией без потерь.
В варианте б), наоборот, некоторая информация утрачивается, поскольку оба города имеют статус 30, но при ЭТОМ нельзя сказать, какой из них как называется. Вторая декомпозиция не является декомпозицией без потерь.
135
На рис. 5.9 |49| показаны два отношения, полуденные путем декомпозиции исходного отношения «КОМНАТЫ».
Рис. 5.9. Исключение избыточного дублирования данных
Теперь удаление информации о Волкове из базы данных не приведет к утере информации о номере телефона в 320-й комнате.
Процедура декомпозиции отношения является основной при нормализации отношений. Однако для осуществления «декомпозиции без потерь» необходимо предварительно выявить так называемые функциональные зависимости.
Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В. Математически функциональная зависимость В от А обозначается записью А—В. Это означает, что во всех кортежах с одинаковым значением атрибута А
атрибут В будет иметь также одно и то же значение. Отметим, что А
И В могут быть составными - состоять из двух и более атрибутов [18].
Функциональная зависимость (ФЗ) называется тривиальной, если
она не может не выполняться. Например:
То есть функциональная зависимость является тривиальной тогда и только тогда, когда правая часть ее символической записи является подмножеством левой части.
С практической точки зрения подобные зависимости не представляют интереса — в отличие от нетривиальных зависимостей, которые действительно являются ограничениями целостности.
Функциональные зависимости — это особый вид ограничений целостности, поэтому понятие ФЗ является семантическим. Распознавание функциональных зависимостей представляет собой часть процесса выяснения смысла тех ИЛИ ИНЫХ данных.
Функциональная взаимозависимость. Если существует функциональная зависимость вида А->В И В->А, то между А и В имеется взаимно однозначное соответствие, или функциональная взаимозависимость. Наличие функциональной взаимозависимости между атрибутами А и В обозначается А <->B.
Например, если в некотором отношении существуют атрибуты «ФИО» и <Номер паспорта», то они являются взаимозависимыми, то есть одному значению атрибута «ФИО» соответствует только одно значение атрибута «Номер паспорта» и наоборот. Правда, это возможно, только если исключается полное совпадение фамилий, имен и отчеств двух людей.
Частичной функциональной зависимостью называется зависимость неключевого атрибута от части составного ключа.
Полная функциональная зависимость зависимость неключевого атрибута от всего составного ключа.
Транзитивная зависимость существует, если для атрибутов А, В, С выполняются условия А->В и В—>С, но обратная зависимость отсутствует.
Между атрибутами может имен, место многозначная зависимость.
В отношении R атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В, не связанных с другими атрибутами из R.
Многозначные зависимости могут быть - один ко многим» (1:М), «многие к одному» (М:1) или «многие ко многим» (М: М).
ОСНОВНОЙ способ определения наличия функциональных зависимостей внимательный анализ семантики атрибутов. Для каждого отношения почти всегда существует определенное множество функциональных зависимостей между атрибутами. Причем если в некотором отношении существует одна или несколько функциональных зависимостей, то из них можно вывести другие функциональные зависимости.
Существует 8 основных правил вывода. Они обеспечивают выявление всех ФЗ. Перечислим эти правила [18J.
1. Правило рефлексивности: если множество В является подмножеством множества А, то А—>В.
2. Правило дополнения: если А—>В, то АС->ВС.
3. Правило транзитивности: если А—>В и В—>С, то А—>С. 1. Правило самоопределения: А—>А.
5. Правило декомпозиции: если А—>ВС, то А—>В и А—>С.
6. Правило объединения: если А—>В и А—>С, то А—>ВС.
7. Правило композиции: если А—>В и С—>D то AC—>BD.
8. Общая теорема объединения: если А—>В и С—>D, то A u ( C - B)—>BD.
Более подробно об использовании правил вывода см. в [18]. Рассмотрим проектирование БД на примере создания БД, содержащей информацию о преподавателях [49]. Выделим атрибуты отношения:
¦ «ФИО" - фамилия и инициалы преподавателя. Возможность
совпадения фамилий и инициалов исключается;
¦ Должность» должность преподавателя;
¦ «Оклад» - оклад преподавателя;
¦ «Стаж» - преподавательский стаж;
¦ <Надбавка» - надбавка за стаж;
¦ «Кафедра» - аббревиатура кафедры, на которой числится преподаватель;
¦ «Дисциплина» - название дисциплины, закрепленной за преподавателем;
¦ " Группа»- код группы, в которой преподаватель проводит занятия;
¦ «Вид занятий» — лекции, практические или лабораторные занятия.
Исходное отношение «ПРЕПОДАВАТЕЛЬ» показано на рис. 5.10[49].
ПРЕПОДАВАТЕЛЬ
138
Отношение «ПРЕПОДАВАТЕЛЬ» содержит избыточное дублирование данных.
Например, повторяются данные о преподавателе, если он ведет разные дисциплины или проводит занятия в нескольких группах.
Отношение имеет составной ключ {ФИО, Дисциплина, Группа}. Данное сочетание атрибутов является ключом при условии, что один и тот же преподаватель не может вести одновременно лекции и практические занятия водной и той же группе.
Анализ семантики атрибутов ПОЗВОЛИЛ ВЫЯВИТЬ следующие функциональные зависимости:
¦ ФИО—>Оклад;
¦ ФИО—>Должность;
¦ ФИО—>Стаж;
¦ ФИО—>Надбавка;
¦ Ф И О—>Кафедра;
¦ Стаж—>Над6авка;
¦ Должность—>Оклад;
¦ Оклад—>Должность;
¦ {ФИО, Дисциплина, Группа}—>Вид занятий.
> Должность
ФИО
Дисциплина
Группа
Оклад
Надбавка
Стаж
Кафедра
Рис. 5.11. Функциональные зависимости между атрибутами [49]
Рассмотрим семантический смысл выявленных ФЗ.
Фамилия, имя и отчество у преподавателей уникальны. Каждому преподавателю однозначно соответствует его стаж (ФИО—>Стаж). Обратное утверждение неверно, так как одинаковый стаж может быть у разных преподавателей.
Каждый преподаватель имеет определенную надбавку за стаж (ФИО—>Надбавка). Обратная функциональная зависимость отсут-
ствует, так как одну и ту же надбавку могут иметь несколько преподавателей.
Каждый преподаватель имеет определенную должность, но одну и ту же должность могут иметь несколько преподавателей (ФИО—>
Должность).
Каждый преподаватель является сотрудником одной и только одной кафедры (ФИО—>кафедра), вместе с тем на одной кафедре могут работать несколько преподавателей.
Каждому преподавателю соответствует определенный оклад, величина которого одинакова для всех преподавателей с одинаковыми должностями. Поэтому ФИО—>Оклад и Должность—>Оклад. Одинаковых окладов для разных должностей не существует, потому Оклад—> Должность.
Одни и тот же преподаватель в одной группе по разным предметам может проводин» разные виды занятий. Определение вида занятий, которые проводит преподаватель, невозможно без указания предмета и группы, поэтому имеется функциональная зависимость {ФИО, Дисциплина, Группа}—>Вид занятий.
Зависимости между атрибутами «ФИО», «Дисциплина» и «Группа» не выделены, поскольку они образуют составной ключ и не учитываются в процессе нормализации исходного отношения.
Выявленные функциональные зависимости необходимо проверить на согласованность с данными исходного отношения «ПРЕПОДАВАТЕЛЬ» (рис. 5.10). Например, значение атрибута "Должность» «ассистент» должно соответствовать значению атрибута "Оклад» «1500» во всех кортежах отношения. Если это так, то функциональная взаимозависимость Должность—>Оклад подтверждается. Верификация ФЗ осуществляется с учетом условий (ограничений целостности).
Отношение находится в первой нормальной форме, если оно удовлетворяет принципам реляционной модели, приведенным в и. 5.3.
Рассматриваемое отношение уже находится в 1НФ.
Как было сказано выше, перевод отношения в следующую нормальную форму осуществляется методом «декомпозиции без потерь».
Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и каждый неключевой атрибут функционально полно зависит от первичного ключа (составного).
Отношение «ПРЕПОДАВАТЕЛЬ» не находится во второй нормальной форме, поскольку можно выделить зависимость атрибутов «Стаж», «Надбавка», « Кафедра», «Должность», «Оклад» от частя ключа (атрибута «ФИО»). Эта частичная зависимость приводит к информационной избыточности и возникновению аномалий.
140
R1
ФИО Дисциплина Группа Вид занятий
ВОЛКОВ И. С. СУБД 81 Практ
ВОЛКОВ И. С. ИС 79 Практ
Белкин А. М. СУБД 81 Лекция
Белкин А. М. ИТУ 81 Практ
Синицын С. С. ИС 79 Лекция
Синицын С. С. ИТУ 81 Лекция
Медведев Е. В. Экономика 70 Лекция
ФИО
Дисциплина
Вид занятий
Группа
R2
ФИО Должность Оклад Стаж Надбавка Кафедра
Волков И. С. ассистент 1500 4 100 ГиМУ
Белкин А. М. доцент 2000 8 300 ГиМУ
Синицын С. С. ассистент 1500 10 400 ГиМУ
Медведев Е. В. ассистент 1500 4 100 Э
ФИО
Оклад
Должность
Надбавка
Стаж
Кафедра
Рис. 5.12. Отношения во второй нормальной форме
Для устранения функциональной зависимости неключевых атрибутов от части ключа и перевода отношения во вторую нормальную
форму необходимо разбить его на несколько отношений, используя операции) проекции.
Во-первых, необходимо построить проекцию без атрибутов, находящихся в частичной функциональной зависимости от первичного ключа.
Во-вторых, необходимо построить проекции на части составного первичного ключа и атрибуты, зависящие от этих частей.
В результате получим два отношения R1 и R2. находящиеся во второй нормальной форме (рис 5.12) [49].
В отношении R первичным ключом является совокупность атрибутов {ФИО, Дисциплина, Группа}. В отношении R2 ключом является атрибут «ФИО».
Отношения Rl и R2 находятся во второй нормальной форме.
Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и каждый неключевой атрибут зависит только от первичного ключа.
Отношение R1 находится в третьей нормальной форме, а отношение R2 нет (см. рис. 5.12). В R2 по-прежнему присутствует информационная избыточность, поэтому требуется дополнительное преобразование.
В отношении R2 присутствуют транзитивные зависимости:
ФИО—>Должность—>Оклад, ФИО—>Оклад—>Должность,
ФИО—>Стаж—>Надбавка
Транзитивные зависимости порождают избыточное дублирование данных. Для устранения таких зависимостей можно воспользоваться операцией проекции на атрибуты, являющиеся причиной транзитивных зависимостей. Преобразуем отношение R2, получив отношения R3, R4 и R5 (рис. 5.13) [49]. Полученное преобразование не является
единственно верным.
Отношения R3, R4, R5 находятся в третьей нормальной форме.
На практике в большинстве случаев приведением отношений к третьей нормальной форме заканчивается процесс проектирования реляционной БД.
Если в отношении имеется зависимость атрибутов составного ключа от неключевых атрибутов, то необходимо привести отношение к усиленной третьей нормальной форме, или нормальной форме Бойса-Кодда.
Отношение находится в нормальной форме Бойса-Кодда, если оно находится в третьей нормальной форме и в нем отсутствуют функциональные зависимости атрибутов составного ключа от неключевых атрибутов.
142
R3
ФИО Должность Стаж Кафедра
Волков И.С. ассистент 4 ГиМУ
Белкин A.M. доцент 8 ГиМУ
СиницынС.С. ассистент 10 ГиМУ
Медведев Е.В. ассистент 4 Э
Должность
ФИО
Стаж
Кафедра
R4
Должность Оклад
ассистент 1500
доцент 2000
Должность
Оклад
R5
Стаж Надбавка
4 100
8 300
10 400
Стаж
> Надбавка
Рис. 5.13. Отношения в третьей нормальной форме
В рассматриваемом примере таких зависимостей нет, поэтому процесс проектирования можно завершить.
Результатом проектирования является реляционная БД как набор взаимосвязанных двумерных таблиц R1, R3, R4, R5. Схема базы данных,
реализованной в СУБД Microsoft Access, представлена на рис. 5.14.
Рис. 5.14. Реляционная база данных
В полученной БД имеет место неизбыточное дублирование данных, но отсутствует избыточное.
Похожие рефераты:
